The data processing resources of business organizations are increasingly taking the form of a distributed computing environment in which data and processing are dispersed over a network comprising many interconnected, heterogeneous and geographically remote computers. Among the reasons for this approach are to offload non-mission-critical processing from the mainframe, to provide a pragmatic alternative to centralized corporate databases, to establish a single computing environment, to move control into the operating divisions of the company, and to avoid having a single point of failure. For example, many business entities have one client/server network installed in each regional office, in which a high-capacity computer system operates as the “server” supporting many lower-capacity “client” desktop computers. The servers in such a business entity are also commonly connected to one another by a higher-level network known as a wide area network. In this manner, users at any location within the business entity can theoretically access resources available in the company's network regardless of where the resource is located.
The flexibility gained for users with this type of arrangement comes with a price, however. It is very difficult to manage such a diverse and widely dispersed network for many reasons. Servers installed in the wide area network are frequently not all of the same variety. One regional office may be using an IBM computer with a UNIX operating system, while another regional office may be using a DEC computer with a VMS operating system. In addition, applications present on the servers throughout the network vary in terms of not only type, but also product release level within an application type. Moreover, the applications available are changed frequently by users throughout the network, and failure events in such a network are usually difficult to catch until after a failure has already occurred.
When an error occurs, the System Administrator or support technicians must determine what caused the error, attempt to recover any lost data, and prevent the error from recurring. It is helpful if applications, operating systems, system service records and important events such as low-memory conditions or excessive attempts to access a disk are known. The System Administrator can use event logs to help determine what conditions caused the error and the context in which it occurred. By periodically viewing the event logs, the System Administrator may be able to identify problems before they cause damage to the computer network.
Although event logs enable the System Administrator to possibly understand the nature of computer network failures, the management of the event logs poses a monumental problem. Event logs grow in size very rapidly and consume large areas of disk space. A large volume of event logs may contain the source of a network failure but sorting though voluminous event logs is a daunting and time consuming task. For example, a computer network supporting the Windows NT platform was introduced by Microsoft® several years ago. System Administrators have struggled with the task of maintaining their event logs ever since.
In some cases, System Administrators choose to have Windows NT computers overwrite old event log entries when the logs become full in a circular action. In most security conscious organizations, however, this is frowned upon since vital information is lost and unrecoverable. Alternatively, System Administrators set up their Windows NT/2000® computers so that no information is overwritten. Unfortunately, this makes the System Administrators clear each log by hand using the Event Viewer application which is a part of the Windows NT/2000® platform.
Even if an System Administrator writes a script to insure the timely backup and clearing of his/her server's event logs, finding a way to centralize the data collected from the computers is another problem. Most organizations require that event log data be stored in different formats, such as native Event Viewer files (.EVT format), comma-delimited text files or actual ODBC Databases like Microsoft Access® and Microsoft® SQL Server. In some cases, organizations may want duplicate sets of the data in different formats, such as EVT files for law enforcement usage, or database tables so that advanced analysis can be performed on the event logs. Gathering the data manually in multiple formats for long-term storage simply requires too many employee hours to implement. More often, event logs are misplaced or neglected, and critical security data is not readily available in the event of a network attack.
Finally, there is no native way in either Microsoft Windows NT® itself or via its resource kit utilities to push-out a unified auditing strategy to all of the servers and workstations which comprise a Windows NT/2000® domain. Although domain-controlling servers replicate their audit policies among one another, stand alone servers and workstations have no mechanism for sharing a centrally defined audit policy. Consequently, if a single server or workstation is compromised on a network, it may not be set up to report the unauthorized access in its security log. Likewise, there is no native way to centralize either event log file size or retention policies. As a result, some computers may inadvertently write over important events when their fixed event log size is exceeded.
One attempt to manage event logs in a computer network focuses on having a manager system deployed on one of the network computers. The other computers in the network have an agent system deployed thereon. Each respective agent system carries out tasks on the computer system in which it is deployed such as event logging. The manager software system commands and controls the operation of all of the agents deployed throughout the computer network. The principle disadvantage to this approach is the inflexibility of the agent system. The manger/agent system of managing event logs has to be deployed on every computer in the network. The manger/agent system does not resolve the voluminous event log storage problems existing on local or sub-network computers of the network. It only adds another layer of control.
It would be desirable to have an agent-free modular system to manage event logs on a computer network. The agent-free modular system would have the flexibility to be deployed as individual modules or a complete system. The agent-free modular system would monitor, archive and analyze event logs in real time in a plurality of different formats to accommodate the various system formats of the computer network. Further, it would be desirable to have means of updating individual modules throughout the computer network from a central location.